1. Field of the Invention
The invention relates to mobile communication systems. Particularly, the invention relates to the performing of packet switched handover in a mobile communication system.
2. Description of the Related Art
The introduction of conversational and streaming services in Global System of Mobile Communications (GSM) has created a demand for efficient handovers from user perspective in GSM/Edge Radio Access Network (GERAN). The General Packet Radio Service (GPRS) and the IP Multimedia System (IMS) support the conversational and streaming services on their side and impose requirements on the GERAN side. It is necessary to be able to perform Packet Switched (PS) handovers frequently enough and to be able to minimize interruptions in a constant packet stream to a mobile terminal. The interruptions must preferably be short enough to enable a packet buffering mechanism in the mobile terminal to hide the interruptions. Previously in GPRS it was sufficient to provide a loss-free link layer service for interactive applications such as Wireless Application Protocol (WAP) browsing. In browsing applications moderate extra delays caused by handovers are acceptable. However, in streaming or conversational class services interruptions in the supposedly constant packet stream are immediately noticeable unless, of course, they can be hidden using large enough buffers in the receiving ends. However, such buffering introduces always a delay in the media streams provided to the user. In the case of conversational voice services any significant delays are unallowable, especially considering other factors already introducing a delay in the speech path such as noise filtering and speech coding.
Reference is now made to FIG. 1, which is a block diagram illustrating the architecture and the protocol stacks in a GPRS system in association with the GERAN. The GPRS system is specified, for example, in the 3GPP specification 23.060. The protocol stacks are illustrated from the user plane point of view. In FIG. 1 there is a Gateway GPRS Support Node (GGSN) 106. GGSN 106 is connected to an external network (not shown) via a Gi interface. The external network may be an arbitrary IP network, for example, the Internet or an intranet. In FIG. 1 there is also a Serving GPRS Support Node (SGSN) 104. GGSN 106 communicates with SGSN 104, which routes packets to and from Mobile Station (MS) 100 via a Base Station Subsystem (BSS). SGSN 104 takes care of the mobility related tasks such as the maintaining of mobile station 100 location information, network registrations, routing area and location updating, Packet Data Context (PDP) activation and deactivation, handovers and the paging of mobile station 100. Part of the above mentioned tasks are naturally done in other network elements with which SGSN 104 is communicating. The GGSN is responsible for routing and tunneling packets to and from a number of SGSN 104 and other SGSNs. The routing is based on SGSN address information maintained in a PDP context information held by GGSN 106 for each network address activated for MS 100, for example, an IP address or an X.25 address or a PPP link.
In FIG. 1, the uppermost protocol layer in MS 100 is the application layer (APPL). The application layer may be any protocol, for example, a WAP protocol or Transmission Control Protocol (TCP) or Universal Datagram Protocol (UDP). Over TCP/IP may be carried, for example, Hypertext Transfer Protocol (HTTP). The application layer communication is exchanged with a peer host, which may be located behind the Gi interface, for example, in the Internet. Below the application layer there is the IP layer or alternatively X.25 layer, which in GPRS is supported by both MS 100 and GGSN 106. The IP address for packets addressed to MS 100 points to GGSN 106. An IP packet 114 is conveyed to MS 100 using GPRS user plane protocols below the IP layer. Between GGSN 106 and SGSN 104 IP packet 114 is conveyed using the GPRS Tunneling Protocol (GTP). A GTP packet carried further over UDP/IP.
In SGSN IP packet 114 data is routed based on MS 100 location information and passed to Sub-Network Dependent Convergence Protocol (SNDCP) layer. SNDCP is specified in the 3GPP specification 44.065. SNDCP layer maps network-level characteristics onto the characteristics of the underlying network. For example, SNDCP takes care of the transmission and reception of Network layer Protocol Data Units (N-PDU) carrying IP packets. For example, IP packet 114 is carried in N-PDU 112. SNDCP multiplexes several packet data protocol packets for the same MS. It segments IP packet 114 to LLC frames, for example, LLC frame 110. It also reassembles packets from LLC frames. Header compression and packet payload compression is also performed at SNDCP layer. SNDCP performs parameter negotiation between MS 100 and SGSN 104. SNDCP buffers N-PDUs in the case of acknowledged mode services.
The Logical Link Control (LLC) layer provides a highly reliable link between MS 100 and SGSN 104. The LLC is specified in 3GPP specifications 44.064 and 04.64. The LLC is independent of the underlying radio protocols and hides the BSS and radio interface related tasks from the LLC layer users. LLC supports variable-length information frames. LLC supports both acknowledged and unacknowledged data transfers, that is, acknowledged and unacknowledged modes of operation. LLC provides services typical to a link layer comprising parameter negotiation, flow control in the Asynchronous Balanced Mode (ABM), sequence control to maintain the ordering of LLC-frames, expedited delivery for high-priority data, error detection, error recovery and indication. LLC performs data confidentiality by means of the ciphering of LLC-frame contents. LLC also supports user identity confidentiality by means of the use of Temporary Logical Link Identity (TLLI) instead of International Mobile Subscriber Identity (IMSI).
The relay layer relays LLC PDUs between the Um and Gb interfaces in the BSS. The Base Station System GPRS Protocol (BSSGP) layer specified in 3GPP specification 08.18 conveys routing and QoS-related information between the BSS and the SGSN. For example, it carries radio resource related requests from the SGSN to the BSS 102. It also carries LLC frames between the BSS and the SGSN. In addition to LLC frames it also carries signaling PDUs associated with GRPS mobility management. The Network Service (NS) layer transports BSSGP PDUs between BSS and SGSN. NS may be based on Frame Relay (FR). The RLC sub-layer within the RLC/MAC layer provides a radio technology dependent reliable link between MS 100 and BSS 102. The MAC sub-layer performs the requesting and reservation of radio resources and maps LLC frames onto the GSM physical channels. The task of the MAC layer is to ensure efficient sharing of common radio resources by several mobile stations. The RLC/MAC layer is defined in the 3GPP specification GSM 04.60.
The standardization organization 3G Partnership Project (3GPP) is currently specifying the packet switched handover for GERAN A/Gb mode. One of the key aspects of the packet switched handover is duplicated packet forwarding to both a source BSS and a target BSS during handover, which has not yet been thoroughly covered in the specifications.
Reference is now made to FIG. 2, which is a block diagram of GPRS architecture illustrating problems in prior art associated with duplicated packet forwarding. According to current GPRS specifications, an LLC entity in a new SGSN can only be started so that an LLC connection is establishing at the request of an SNDCP entity or the peer LLC entity. An LLC entity can only be created in its initial state where the LLC connection variables have their initial values. In FIG. 2 there is an MS 100, Base Transceiver Stations (BTS) 224-228 and Base Controller Stations (BSC) 210-214 in BSS 216. There is a GGSN 200, which is connected to IP network 201. From IP network 201 is received a downlink packet stream 246 for which a real-time service is required. Initially, downlink packet stream 246 is tunneled to SGSN 202 as packet stream 240. Initially, SGSN 202 routes packet stream 240 to MS 100 via BSC 212 and BTS 222 as packet stream 242 using an LLC connection terminating at an LLC entity 230, which is located in MS 100. BSC 212 and BTS 222 are referred to as source BSS 262. MS 100 communicates with BSC 212 via BTS 222. BSC 212 performs handover related tasks including the handover determination algorithms and decisions. In handover related signaling an SGSN communicates with a BSC within a BSS. Similarly, in handover related signaling an MS communicates with a BSC within a BSS. The signaling between an MS and a BSC goes via a BTS.
However, when MS 100 receives a report indicating that a cell served by BTS 224 has better radio quality, it must start performing handover to the cell served by BTS 224. The new cell is under the area of a new SGSN 204. After the handover, packet stream 246 should be routed to MS 100 from GGSN 200 via SGSN 204, BSC 214 and BTS 224. BSC 214 and BTS 224 are also referred to as a target BSS 264. While the handover is not fully complete, SGSN 202 must forward packets to both BSC 212 and SGSN 204. In order to be able to process packets from packet stream 240 SGSN 204 must receive them as a GTP tunneled packet stream 241 from SGSN 202. Packets from GTP tunneled packet stream 241 are forwarded in SGSN 204 to its LLC entity 254. The LLC entity is started from initial state with initial LLC connection variables. GTP tunneled packet stream 241 is routed from SGSN 204 as packet stream 244 carried over an LLC connection. The problem in the packet duplicated forwarding mechanism described above is that LLC entity 254 in the new SGSN, namely SGSN 204, has different state compared to LLC entity 252 and LLC entity 230. This means that LLC entity 230 in MS 100 receives packets from two different independent LLC entities. The corresponding peer LLC entity 230 in MS 100 is not capable of receiving simultaneously packets from two different LLC entities, if the states of the LLC entities comprising the LLC variables are not synchronized. The different states essentially lead to the rejection of LLC frames carrying packet stream 244 or the receiving of duplicate LLC frames in an uncontrolled manner.
The rejection is due to the fact that LLC entity 252 sends LLC frames with sequence numbers that are overlapping with the sequence numbers sent by LLC entity 254 even though they are different LLC frames. Frames are rejected in LLC entity 230 also due to the fact that LLC entity 254 sends LLC frames using different ciphering parameters. Because the ciphering parameters are different, LLC entity 230 is unable to decipher the LLC frames and discards them due to failing Frame Check Sequence (FCS) verification. A further problem is that SGSN 204 is unaware of the LLC frame sizes negotiated between MS 100 and SGSN 202. If SGSN 204 uses values that exceed the maximum values supported by MS 100, it discards all LLC frames. This in turn may lead to the releasing of the PDP context carrying packets streams 240, 241, 242 and 244. MS 100 may additionally also perform reset.
As explained in the 3GPP specification 44.064, the ciphering parameters for LLC frames comprise IOV, LFN, OC and SX. IOV is an Input Offset Value, which is a 32 bit random value generated by the SGSN. LFN is the LLC Frame Number (LFN) in the LLC frame header. OC is an overflow counter that is calculated and maintained independently at the sending and the receiving sides. An OC for acknowledged operation must be set to 0 whenever asynchronous balanced mode operation is re-established for the corresponding Data Link Connection Identifier (DLCI). An LLC layer connection is identified using DLCI, which consists of Service Access Point Identifier (SAPI) and the TLLI associated with MS 100. OC shall be incremented by 512 every time when the corresponding LFN rolls over. Due to this fact, OC is never sent directly in LLC frames. The aim of OC is to add variation to the ciphering process in order to make it more robust. SX is an XOR mask calculated from the LLC entity identifier. There are two IOV values, one for numbered information frames associated with acknowledged operation and another for unconfirmed information frames associated with unacknowledged operation. There are also two LFN values, one for acknowledged operation and another for unacknowledged operation. There are four OC counters associated with each DLCI. There is one OC counter per operation mode, which is either unacknowledged or acknowledged, and direction of transmission, which is either uplink or downlink.
Naturally, the session key Kc used in the ciphering algorithm is one of the ciphering parameters.
Reference is now made to FIG. 3, which is a signaling diagram illustrating signaling during a packet switched handover in accordance with the current 3GPP proposals. The current proposals are described in TSG document GP-032710 “Packet Switched Handover for GERAN A/Gb mode, Stage 2”, version 0.2.0, 2004-01. The architecture associated with the signaling is as illustrated in FIG. 2. MS 100 sends radio quality measurement information pertaining to neighboring cells to source BSS 262 using message 301. Based on the measurement information source BSS 262 determines that handover is required. At time t0 source BSS 262 determines that handover is to be performed to a new cell, which is in the area of a new SGSN, which is SGSN 204. Source BSS 262 sends a PS Handover Required message 302 to old SGSN 202. The message comprises, for instance, the source cell, the target cell, TLLI, cause and a transparent container. SGSN 202 determines based on the target cell if the handover is an intra- or inter-SGSN handover. SGSN 202 determines the identity of the new SGSN and sends a Prepare PS Handover Request message 303 to SGSN 204. SGSN 204 sends a PS Handover Required message 304, which requests target BSS 264 to reserve radio resources for MS 100 in the target cell. When radio resources have been successfully allocated, target BSS 264 sends a PS Handover Request Acknowledge message 305 indicating successful allocation. SGSN 204 sends a Prepare PS Handover Response message 306 to SGSN 202, which tells, among other things, that SGSN 202 may issue to MS 100 a command to complete handover to the new cell. SGSN 202 receives message 306 at time t1.
However, simultaneously a packet from GTP packet stream 307 is received by SGSN 202. SGSN 202 forwards packets one by one from GTP packet stream 307 to SGSN 204 as packet stream 308. SGSN 204 sends packets from packet stream 308 further to target BSS 264 as packet stream 309. Target BSS forwards packets from packet stream 308 to MS 100 as packet stream 310. There is a delay before MS 100 is able to receive packets from SGSN 204 via target BSS 264. SGSN 202 sends PS Handover Command message 311 to source BSS 262. Source BSS sends further PS Handover Command message to MS 100. Thereupon, MS 100 tunes to the radio channel and timeslot allocated in the target cell by target BSS 264. This is illustrated using arrow 312. Target BSS 264 sends Physical information to MS 100 for MS 100 to synchronize. After MS 100 has synchronized, it sends a PS Handover Complete message 314 to target BSS 264 at time t2. Only after time t2 MS 100 is prepared to receive packets via target BSS 264 normally, which shows that there is an intolerable delay unless MS 100 receives packets via both target BSS 264 and source BSS 262. Target BSS 264 sends a PS Handover Complete message 315 to SGSN 204. Thereupon, SGSN 204 performs PDP context update messaging represented using arrows 316 and 317 with GGSN 200. PDP context update indicates to GGSN 200 the address of current SGSN 204. After having received PDP context update at time t3, GGSN 200 is able to start routing GTP packet stream 318 to right SGSN, which is now SGSN 204. Thereupon, MS 100 receives packet stream 320 from target BSS 264, which has received it from SGSN 204 as packet stream 319.
Reference is now made to FIG. 4, which is signaling diagram illustrating the delay associated with a solution, which merely forwards packets from a source node to a target node during handover processing. The solution is similar to the solution utilized in UMTS in association with Serving Radio Network Server SRNS relocation. SRNS relocation is explained in 3GPP 23.060. In FIG. 4 a source node 452 receives a packet stream 401 sent by an upper node 450, which is connected to an IP network 451. At time to upper node sends a specific packet 460 in packet stream 401. Source node forwards packet stream further 402 to MS 100 via an access network 456. At time t1 MS 100 decides to start using a target node 454 instead of source node 452 for receiving packet streams. At time t1 MS 100 acknowledges last frame received via source node 452 using message 403. Packet 460 has not been completely received, for example the last frame from packet 460 may be pending. MS 100 sends a request message 403 for source node 452 indicating the abandoning of source node 452 for MS 100 traffic. After receiving message 403, source node 452 starts forwarding all packets addressed to MS 100 via target node 454 as packet stream 405. Packet stream 405 is forwarded by target node 454 to MS 100 as packet stream 406. At time t2 MS 100 receives a first packet since MS 100 received the last frame via source node 452 at time t1. The time difference between t1 and t2 represents the gap in the receiving of packets at MS 100, whereas the time difference between t0 and t2 represent a delay in receiving packet 460 from upper node 450 to MS 100. The delays explained above are intolerable for real-time services.
As has been illustrated in association with FIGS. 2, 3 and 4, there are problems in performing packet switched handover using current GPRS architecture and the solutions proposed in prior art. On the one hand, it must be possible for an MS to receive packets simultaneously from a source node and a target node during the handover signaling. On the other hand, this is not possible in current GPRS specifications and leads to the rejection of forwarded frames at the MS side.